In computer and telecommunications networks, presence information conveys the availability and willingness of a user (called a presentity) to communicate. A user's client provides presence information to a presence service to be stored and distributed to other users (called watchers) to convey the user's communication state. Presence information has wide application in voice over IP (VoIP) and instant messaging (IM) systems.
A user's client may publish a presence state to indicate its current communication status. This published state informs others that wish to contact the user of the user's availability and willingness to communicate. The most common use of presence today is the status indicator displayed on most instant messaging clients. A simpler everyday example is the ‘on-hook’ or ‘off-hook’ state of a telephone receiver, resulting in a distinctive ring tone for a caller. Some states that offer extended information on the user's availability are “free for chat”, “away”, “do not disturb”, and “out to lunch”, which are often seen on many modern instant messaging clients. Rich information such as user mood and location may be also included. Basically information published by a presentity has two parts, user information (the online, busy, in meeting, etc. states) and device information (whether the presentity is online and available for communications). The presence server then aggregates the information from all of the presentities associated with a single user and published a presence document. This presence document represents the availability of the user. “Hook status” can be either integrated into the aggregation calculation, or there could be a separate audio aggregation.
Users have the potential to publish different presence states depending on who the communicator (or watcher) is. A worker may only want colleagues to see detailed presence information during office hours, for instance. Some users may want to only publish information to a select few. Basic versions of this idea are already common in instant messaging clients as a ‘Block’ facility, where users can appear as unavailable to selected watchers.
Electronic mail, abbreviated e-mail or e-Mail or email, is a method of composing, sending, storing, and receiving messages over electronic communication systems. The term e-mail applies both to the Internet e-mail system based on the Simple Mail Transfer Protocol (SMTP) and to intranet systems allowing users within one company to e-mail each other. Often these workgroup collaboration organizations may use the Internet protocols for internal e-mail service.
For example, let's examine a typical sequence of events that takes place when Mary composes a message using her mail user agent (MUA). She types in, or selects from an address book, the e-mail address of her correspondent. She hits the “send” button. Her MUA formats the message in Internet e-mail format and uses the SMTP protocol to send the message to the local mail transfer agent (MTA), in this case smtp.a.org, run by Mary's Internet Service Provider (ISP).
The MTA looks at the destination address provided in the SMTP protocol (not from the message header), in this case ralph@b.org. A modern Internet e-mail address is a string of the form localpart@domain.example, creating a Fully Qualified Domain Address (FQDA). The part before the @ sign is the local part of the address, often the username of the recipient, and the part after the @ sign is a domain name. The MTA looks up this domain name in the Domain Name System (DNS) to find the mail exchange servers accepting messages for that domain.
The DNS server for the b.org domain, ns.b.org, responds with an MX record listing the mail exchange servers for that domain, in this case mx.b.org, a server run by Ralph's ISP. smtp.a.org sends the message to mx.b.org using SMTP, which delivers it to the mailbox of the user Ralph. Ralph presses the “get mail” button in his MUA, which picks up the message using the Post Office Protocol (POP3). Other methods can be used to retrieve messages as well, such as IMAP4 (Internet Message Access Protocol) or email systems such as Exchange/Outlook and Domino/Notes.
An Email MTA can go down or become backed up for many reasons, such as routine maintenance, Denial-Of-Service attacks, virus checking, server failure, etc. When this occurs, MTA's upstream from the downed MTA continue to receive and queue messages. When the MTA comes up again, it is faced with an often daunting amount of email to deliver. It can take hours or even days to clear the backlog.
Therefore, it is desirable to have a system that leverages presence information to prioritize the resource backlog, delivering the resource first to those users who are in presence states that indicate they are likely to want to access the resource and deferring delivery to other users who are not in those presence states.